home *** CD-ROM | disk | FTP | other *** search
/ IRIX Base Documentation 2002 November / SGI IRIX Base Documentation 2002 November.iso / usr / share / catman / a_man / cat1 / inetd.z / inetd
Encoding:
Text File  |  2002-10-03  |  14.5 KB  |  330 lines
  1.  
  2.  
  3.  
  4. IIIINNNNEEEETTTTDDDD((((1111MMMM))))                                                            IIIINNNNEEEETTTTDDDD((((1111MMMM))))
  5.  
  6.  
  7.  
  8. NNNNAAAAMMMMEEEE
  9.      inetd - Internet ``super-server''
  10.  
  11. SSSSYYYYNNNNOOOOPPPPSSSSIIIISSSS
  12.      ////uuuussssrrrr////eeeettttcccc////iiiinnnneeeettttdddd [ ----RRRR _r_a_t_e ] [ ----dddd ] [ ----llll _q_l_e_n ] [ ----ssss ]
  13.          [ configuration-file ]
  14.  
  15. DDDDEEEESSSSCCCCRRRRIIIIPPPPTTTTIIIIOOOONNNN
  16.      When _i_n_e_t_d is started at boot time by /_e_t_c/_i_n_i_t._d/_n_e_t_w_o_r_k, it reads its
  17.      configuration information from the /_e_t_c/_i_n_e_t_d._c_o_n_f and listens for
  18.      connections on certain internet sockets.  When a connection is found on
  19.      one of its sockets, it decides what service the socket corresponds to,
  20.      and invokes a program to service the request.  After the program is
  21.      finished, it continues to listen on the socket (except in some cases
  22.      which will be described below).  Essentially, _i_n_e_t_d allows running one
  23.      daemon to invoke several others, reducing load on the system.
  24.  
  25. OOOOPPPPTTTTIIIIOOOONNNNSSSS
  26.      ----RRRR   This option controls the maximum number of times a service can be
  27.           invoked in one minute; the default is 1000.
  28.  
  29.      ----dddd   This option turns on debugging information.  Note that this can
  30.           confuse some applications; use this cautiously.
  31.  
  32.      ----ffff   This option is no longer supported and will simply cause a warning
  33.           message to be included in the syslog if used.
  34.  
  35.      ----llll   This option changes the listen queue length used for TCP sockets.
  36.           By default this value is 255.
  37.  
  38.      ----ssss   Causes inetd to just parse the configuration file (default is
  39.           /etc/inetd.conf) and report any errors.  Do not need superuser
  40.           privileges to run inetd using this option.
  41.  
  42.      To specify a different configuration file, put its pathname in the file
  43.      /_e_t_c/_c_o_n_f_i_g/_i_n_e_t_d._o_p_t_i_o_n_s.
  44.  
  45. CCCCOOOONNNNFFFFIIIIGGGGUUUURRRRAAAATTTTIIIIOOOONNNN FFFFIIIILLLLEEEE
  46.      Each line of the configuration file must be a valid service or a comment.
  47.      Comments are denoted by a ``#'' at the beginning of a line.  Each field
  48.      in a line must be specified, with values for each field separated by a
  49.      tab or a space. The fields are as follows:
  50.           service name
  51.           socket type
  52.           protocol
  53.           wait/nowait
  54.           user
  55.           server program
  56.           server program arguments
  57.  
  58.  
  59.  
  60.  
  61.  
  62.  
  63.                                                                         PPPPaaaaggggeeee 1111
  64.  
  65.  
  66.  
  67.  
  68.  
  69.  
  70. IIIINNNNEEEETTTTDDDD((((1111MMMM))))                                                            IIIINNNNEEEETTTTDDDD((((1111MMMM))))
  71.  
  72.  
  73.  
  74.      There are three types of services that _i_n_e_t_d can start: standard, RPC and
  75.      TCPMUX.  A standard service has a well-known port assigned to it and is
  76.      listed in /_e_t_c/_s_e_r_v_i_c_e_s or the NIS _s_e_r_v_i_c_e_s map (see _s_e_r_v_i_c_e_s(4)); it may
  77.      be a service that implements an official Internet standard or is a BSD
  78.      Unix-specific service.  RPC services use the Sun RPC calls as the
  79.      transport; such services are listed in /_e_t_c/_r_p_c or the NIS _r_p_c map (see
  80.      _r_p_c(4)).  TCPMUX services are nonstandard services that do not have a
  81.      well-known port assigned to them.  They are invoked from _i_n_e_t_d when a
  82.      program connects to the ``tcpmux'' well-known port and specifies the
  83.      service name. This feature is useful for adding locally-developed
  84.      servers.
  85.  
  86.      For standard Internet services, the _s_e_r_v_i_c_e _n_a_m_e field is the name of a
  87.      valid service in the _s_e_r_v_i_c_e_s(4) database.  For ``internal'' services
  88.      (discussed below), the service name _m_u_s_t be the official name of the
  89.      service (that is, the first field in /_e_t_c/_s_e_r_v_i_c_e_s).  For RPC services,
  90.      the value of the _s_e_r_v_i_c_e _n_a_m_e field consists of the RPC service name,
  91.      followed by a slash and either a version number or a range of version
  92.      numbers (e.g., mountd/1).  For TCPMUX services, the value of the _s_e_r_v_i_c_e
  93.      _n_a_m_e field consists of the string ``tcpmux'' followed by a slash and the
  94.      locally-chosen service name. If the service name begins with a ``+'', it
  95.      indicates _i_n_e_t_d will handle the initial handshake with the requesting
  96.      program, otherwise the service is responsible for the handshake.  (The
  97.      handshake is described in the _i_n_e_t_d section in the _I_R_I_X _N_e_t_w_o_r_k
  98.      _P_r_o_g_r_a_m_m_i_n_g _G_u_i_d_e.)  The service names listed in /_e_t_c/_s_e_r_v_i_c_e_s and the
  99.      name ``help'' are reserved.  The ``help'' name causes _i_n_e_t_d to list
  100.      available TCPMUX services.  Private protocols should use a service name
  101.      that has a high chance of being unique.  A good practice is to prefix the
  102.      service name with the name of your organization.  Multiple versions of a
  103.      protocol can suffix the service name with a protocol version number.
  104.  
  105.      The _s_o_c_k_e_t _t_y_p_e should be one of ``stream'', ``dgram'', or ``raw'',
  106.      depending on whether the socket is a stream, datagram, or raw socket.
  107.      TCPMUX services must use ``stream.''
  108.  
  109.      The _p_r_o_t_o_c_o_l must be a valid protocol as given in /_e_t_c/_p_r_o_t_o_c_o_l_s (see
  110.      _p_r_o_t_o_c_o_l_s(4)).  Examples might be ``tcp'' or ``udp''.  For RPC services,
  111.      the field consists of the string ``rpc'' followed by a slash and the name
  112.      of the protocol (e.g., rpc/tcp or rpc/udp for an RPC service using the
  113.      TCP or UDP protocol as a transport mechanism. If 2 RPC services use the
  114.      same server program with different protocol such as tcp or udp, the 2
  115.      services need to be based on protocol lexicographic order).  TCPMUX
  116.      services must use ``tcp.''
  117.  
  118.      The _w_a_i_t/_n_o_w_a_i_t entry specifies whether the server that is invoked by
  119.      _i_n_e_t_d will take over the socket associated with the service access point,
  120.      and thus whether _i_n_e_t_d should wait for the server to exit before
  121.      listening for new service requests.  Datagram servers must use wait, as
  122.      they are always invoked with the original datagram socket bound to the
  123.      specified service address.  These servers must read at least one datagram
  124.      from the socket before exiting.  If a datagram server connects to its
  125.      peer, freeing the socket so _i_n_e_t_d can received further messages on the
  126.  
  127.  
  128.  
  129.                                                                         PPPPaaaaggggeeee 2222
  130.  
  131.  
  132.  
  133.  
  134.  
  135.  
  136. IIIINNNNEEEETTTTDDDD((((1111MMMM))))                                                            IIIINNNNEEEETTTTDDDD((((1111MMMM))))
  137.  
  138.  
  139.  
  140.      socket, it is said to be a ``multi-threaded'' server; it should read one
  141.      datagram from the socket and create a new socket connected to the peer.
  142.      It should fork, and the parent should then exit to allow _i_n_e_t_d to check
  143.      for new service requests to spawn new servers.  Datagram servers which
  144.      process all incoming datagrams on a socket and eventually time out are
  145.      said to be single-threaded.  _T_a_l_k_d(8) is an example of the single-
  146.      threaded datagram server. _T_f_t_p_d(8) is an example of a multi-threaded
  147.      datagram server.
  148.  
  149.      Servers using stream sockets generally are multi-threaded and use the
  150.      nowait entry.  Connection requests for these services are accepted by
  151.      inetd, and the server is given only the newly-accepted socket connected
  152.      to a client of the service.  Most stream-based services operate in this
  153.      manner.  Stream-based servers that use wait are started with the
  154.      listening service socket, and must accept at least one connection request
  155.      before exiting.  Such a server would normally accept and process incoming
  156.      connection requests until a timeout.  RPC services usually wait.  TCPMUX
  157.      services must use nowait.
  158.  
  159.      The _u_s_e_r field should contain the user name of the user as whom the
  160.      server should run.  This allows for servers to be given less permission
  161.      than root.
  162.  
  163.      The _s_e_r_v_e_r _p_r_o_g_r_a_m field should contain the pathname of the program which
  164.      is to be executed by _i_n_e_t_d when a request is found on its socket.  If
  165.      _i_n_e_t_d provides this service internally, this field should be
  166.      ``internal''.  For non-internal services, the arguments to the server
  167.      program should be just as they normally are, starting with argv[0], which
  168.      is the name of the program. There is a limit of 11 arguments per program
  169.      (including argv[0]).  A `?' character, placed just before the server
  170.      program pathname, causes _i_n_e_t_d to suppress error logging of a missing
  171.      server.  As shipped, /_e_t_c/_i_n_e_t_d._c_o_n_f uses `?' to suppress error logging
  172.      for servers that are included in optional software packages.
  173.  
  174.      _I_n_e_t_d provides several trivial services internally by use of routines
  175.      within itself.  These services are ``echo'', ``discard'', ``chargen''
  176.      (character generator), ``daytime'' (human readable time), ``time''
  177.      (machine readable time, in the form of the number of seconds since
  178.      midnight, January 1, 1900), and ``tcpmux'' (service multiplexor). All of
  179.      these services are TCP-based.  For details of these services, consult
  180.      RFCs 862, 863, 864, 867, 868, and 1078.
  181.  
  182.      _I_n_e_t_d rereads its configuration file when it receives a hangup signal,
  183.      SIGHUP.  Services may be added, deleted or modified when the
  184.      configuration file is reread.  To disable a service, add the comment
  185.      character ``#'' at the beginning of the service's line in inetd.conf and
  186.      send SIGHUP to _i_n_e_t_d with the command
  187.  
  188.           /etc/killall -HUP  inetd
  189.  
  190.  
  191.  
  192.  
  193.  
  194.  
  195.                                                                         PPPPaaaaggggeeee 3333
  196.  
  197.  
  198.  
  199.  
  200.  
  201.  
  202. IIIINNNNEEEETTTTDDDD((((1111MMMM))))                                                            IIIINNNNEEEETTTTDDDD((((1111MMMM))))
  203.  
  204.  
  205.  
  206. EEEERRRRRRRROOOORRRR MMMMEEEESSSSSSSSAAAAGGGGEEEESSSS
  207.      _I_n_e_t_d logs error messages using _s_y_s_l_o_g(3B).  Important error messages and
  208.      their explanations are:
  209.  
  210.           _s_e_r_v_i_c_e/_p_r_o_t_o_c_o_l server failing (looping), service terminated.
  211.  
  212.      The number of requests for the specified service in the past minute
  213.      exceeded the limit. The limit exists to prevent a broken program or a
  214.      malicious user from swamping the system.  This message may occur for
  215.      several reasons:  1) there are lots of hosts requesting the service
  216.      within a short time period, 2) a 'broken' client program is requesting
  217.      the service too frequently, 3) a malicious user is running a program to
  218.      invoke the service in a 'denial of service' attack, or 4) the invoked
  219.      service program has an error that causes clients to retry quickly.  Use
  220.      the ----RRRR option, as described above, to change the rate limit.  Once the
  221.      limit is reached, the service will be reenabled automatically in 10
  222.      minutes.
  223.  
  224.  
  225.           _s_e_r_v_i_c_e/_p_r_o_t_o_c_o_l: such user '_u_s_e_r', service ignored
  226.           _s_e_r_v_i_c_e/_p_r_o_t_o_c_o_l: getpwnam: _u_s_e_r: No such user
  227.  
  228.      No entry for _u_s_e_r exists in the _p_a_s_s_w_d file. The first message occurs
  229.      when _i_n_e_t_d (re)reads the configuration file. The second message occurs
  230.      when the service is invoked.
  231.  
  232.  
  233.           _s_e_r_v_i_c_e: can't set uid _n_u_m_b_e_r
  234.           _s_e_r_v_i_c_e: can't set gid _n_u_m_b_e_r
  235.  
  236.      The user or group ID for the entry's _u_s_e_r is invalid.
  237.  
  238.  
  239.           too many services: open-file limit reached.
  240.  
  241.      The number of services in the configuration file exceeds the number of
  242.      file descriptors that _i_n_e_t_d can keep open.  Unnecessary services must be
  243.      removed or commented out or the kernel must be reconfigured to increase
  244.      the limit (the NOFILES parameter in /_v_a_r/_s_y_s_g_e_n/_m_a_s_t_e_r._d/_k_e_r_n_e_l.)
  245.  
  246. EEEEXXXXAAAAMMMMPPPPLLLLEEEESSSS
  247.      Here are several example service entries for the various types of
  248.      services
  249.  
  250.           ftp          stream tcp     nowait root  /usr/etc/ftpd         ftpd -l
  251.           ntalk        dgram  udp     wait   root  /usr/etc/talkd        talkd
  252.           rusersd/1    dgram  rpc/udp wait   root  /usr/etc/rpc.rusersd  rusersd
  253.           tcpmux/+date stream tcp     nowait guest /bin/date             date
  254.  
  255.  
  256.  
  257.  
  258.  
  259.  
  260.  
  261.                                                                         PPPPaaaaggggeeee 4444
  262.  
  263.  
  264.  
  265.  
  266.  
  267.  
  268. IIIINNNNEEEETTTTDDDD((((1111MMMM))))                                                            IIIINNNNEEEETTTTDDDD((((1111MMMM))))
  269.  
  270.  
  271.  
  272. NNNNOOOOTTTTEEEE
  273.      If NIS is enabled on your system, _i_n_e_t_d uses the NIS equivalents of
  274.      /_e_t_c/_s_e_r_v_i_c_e_s and /_e_t_c/_r_p_c.  Make sure your NIS server's _s_e_r_v_i_c_e_s and _r_p_c
  275.      databases contain the entries listed in these files.
  276.  
  277. NNNNOOOOTTTTEEEESSSS
  278.      iiiinnnneeeettttdddd has a limit of 512 characters per line of the configuration file.
  279.      Exceeding this limit may cause inetd to terminate abnormally.
  280.  
  281.      If both TCP and UDP services are listed for an RPC service, the TCP
  282.      service should be listed first.
  283.  
  284. SSSSEEEEEEEE AAAALLLLSSSSOOOO
  285.      ftpd(1M), rexecd(1M), rlogind(1M), rshd(1M), telnetd(1M), tftpd(1M).
  286.      sockets programming chapter in the _I_R_I_X _N_e_t_w_o_r_k _P_r_o_g_r_a_m_m_i_n_g _G_u_i_d_e.
  287.      RFCs are available from the Network Information Center at SRI
  288.      International, Menlo Park, CA.
  289.  
  290.  
  291.  
  292.  
  293.  
  294.  
  295.  
  296.  
  297.  
  298.  
  299.  
  300.  
  301.  
  302.  
  303.  
  304.  
  305.  
  306.  
  307.  
  308.  
  309.  
  310.  
  311.  
  312.  
  313.  
  314.  
  315.  
  316.  
  317.  
  318.  
  319.  
  320.  
  321.  
  322.  
  323.  
  324.  
  325.  
  326.                                                                         PPPPaaaaggggeeee 5555
  327.  
  328.  
  329.  
  330.